Today's businesses supply customers with a complex array of end services and/or products--each such end service or product may, in turn, comprise a number of constituent services and products. A typical example is that of a vendor of computer systems for a variety of customers (e.g. individual home users interested in personal computers, businesses interested in client/server systems, etc). Such a vendor is often faced with the task of recommending to the customer an optimal "configuration" to meet the customer's particular needs. More precisely, a "configuration" is a collection of constituent parts that comprise an end product or service. A "product" may comprise one or more physical objects or one or more services or any combination of products and services.
The recommendation of a particular system configuration depends upon both the external needs of the customer and the internal needs of the constituent parts that comprise the end product. For example, such a vendor may recommend to the customer a particular configuration that has a certain amount of disk space storage, a certain number of disk drives, choice of monitor, and the like to meet the desired level of functionality or price/performance desired by the customer.
From these external customer needs, individual parts comprising the end system are identified. To supply a completely usable computer system, however, the needs of the identified parts must also be satisfied by the system when ultimately put together in a unified system. For example, the fact that a desired configuration has 2 disk drives and a CD-ROM drive means that the system should be equipped with a sufficient power supply and space in the cabinet to house these various drives. These "internal" needs are not necessarily known to the user at the time of order; but must be satisfied nonetheless.
Recommending a suitable configuration may be a complex task whose complexity grows with the number of constituent parts, the external needs of the customer, and the internal needs of the parts when considered as a whole. To aid such vendors, "configuration systems" (or "configurators") have been developed that automate, partially or otherwise, the process of choosing a particular configuration that makes sense for the customer.
These configurators typically comprise large software modules that in some sense capture the nature of the product of the vendor. For example, the configurator itself contains information concerning the various components that comprise the product and the various choices that might go into selecting a suitable set of such components to comprise an end product. Additionally, some configurators allow for user preferences to be considered by the system in order to customize an order. For example, a user might specify a price or a performance need that would be considered by the configurator while deciding upon a set of possible configurations for the user.
Adding such information and knowledge of the vendor's product typically requires a certain amount of programming. Some configurators employ a rule-based expert system to specify the relationships between the various components and evaluate potential configurations against a set of user and product constraints. These rules are input into a knowledge base that is then acted upon by an inference engine. In response to a query, the inference engine accesses the rules that represent the various constraints and relationships of the end product and a set of possible configurations that satisfy those constraints and relationships is produced.
Other configurators use an object oriented programming approach to capture the various relationships. The end product may be thought of as a subassembly of parts that may themselves be subassemblies. Parts that are functionally equivalent to one another (i.e. may be substantial substitutes for one another to meet a certain system requirement) may be represented as members of a "class".
More specifically, a class is a description of a set of objects that have similar characteristics, attributes, and behaviors. Individual members of a class are "instances" of the class. The action in a object oriented program takes place by passing messages to and from objects. An object is said to "behave" in a certain way in response to messages passed to it. Usually, the behavior is the execution of a procedure that bears the same name as the message. Classes are usually convenient stores of behaviors that are common to all the instances comprising the class. Thus, when a message is passed to an instance, its behavior is determined by its class--that is, the appropriate procedure is found in the class, and not in the instance itself. These procedures and class definitions are commonly written in an object-oriented programming language such as C++ or Smalltalk.
The common aspect to these typical configurators is that a good deal of programming is required to capture the "domain" of a vendor's end products. A "domain" of an end product is the set of information needed to create a useful model of the end product. Such information includes a list of constituent parts, the relationships among these parts, the resources of the parts, user needs, and the like. Current configurators are largely end-products in themselves that are sold to the vendor.
The drawback to these configurators, from the standpoint of the vendor, is the investment of time and money that is necessary to create them. The vendor usually contracts with programmers--either independent consultants or internal employees--that must spend time learning the products of the vendor and typical external and internal needs comprising and end product. This process can be a time consuming task for the vendor--time necessary for the vendor to teach the programmer. Additionally, the expense in wages and opportunity costs in creating the configurator represent a considerable investment.
Another drawback is the inflexibility of the final configurator design. Once coded, the configurator embodies a certain amount of knowledge of the vendor's products. If a change is made to vendor's product line (or if external needs of the customer or internal needs of the constituent parts change), it may require another substantial investment of the vendor to update the configurator. Without the ability to make easy extensions to the configurator, its static and complex nature make it difficult for the configurator to keep up with such changes.
Thus, there is a need for a system (i.e. a "configurator generator") that allows vendors themselves to construct their own configurators without the need for expert programming services. Additionally, there is a need for such a system to allow for easy editing and extension of any vendor-created configurator.
It is therefore an object of the present invention to produce a system that allows for vendors to create their own configurators using easily understood graphical interfaces.
It is another object of the present invention to produce a configurator generator that has easy editing facilities to allow the vendor to update information concerning end products, external customer needs, and internal part needs.